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DETAILED ACTION 



Claim Rejections - 35 USC § 103 

1 . The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

2. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1 , 148 
USPQ 459 (1966), that are applied for establishing a background for determining 
obviousness under 35 U.S.C. 103(a) are summarized as follows: 

1 . Determining the scope and contents of the prior art. 

2. Ascertaining the differences between the prior art and the claims at issue. 

3. Resolving the level of ordinary skill in the pertinent art. 

4. Considering objective evidence present in the application indicating 
obviousness or nonobviousness. 

3. Claims 16 to 22, 30, 34, and 36 to 39 are rejected under 35 U.S.C. 103(a) as 

being unpatentable over Walker, et al. (U.S. patent 6,024,640 A) over Schneier, et al. 
(U.S. patent 5,871 ,398 A). 

4. As to Claim 16: Walker in '640 teaches a gaming system adapted to facilitate the 
play of wager-based games on a personal gaming device (Abst., Fig. 1). The physical 
game server of '640 is configured to accept input regarding a specific number of wager- 
based games to be played (52, Fig. 3) on an associated hand-held personal gaming 
device (Fig. 1 3). The game server of '640 generates a predetermined game outcome 
for each specific wager-based game played on the personal gaming device 
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(predetermined games, Col. 3, Lines 27 to 35). The game server of '640 transmits data 
regarding the predetermined outcome of each of the specific number of games 
(outcome transfer to HTV, Col. 5, Lines 49 to 53) to a storage device for use by the 
personal gaming device (outcomes duplicately stored on LCC and memory on HTV, 
Col. 6, Lines 1 to 4, Col. 8, Lines 20 to 27, Col. 3, Lines 36 to 45; HTV RAM and ROM, 
Col. 1 1 , Lines 46 to 51 ) for future game play. The LCC of '640 is also a financial server 
that tracks financial data related to the generated predetermined game outcomes (LCC 
memory 52, 56, 58, 74, 76, 79, 72, 78, Fig. 3; Col. 8, Line 63 to Col. 9, Line 4; Col. 1 1 , 
Lines 3 to 14), wherein the wager-based games involve the placement of wagers, the 
play of games based on the wagers, and the grant of payouts based on the outcomes of 
the games. '640 teaches the game server being configured to generate the 
predetermined game outcome for one or more of the specific number of wager-based 
games (Col. 5, Lines 1 to 35 generally; RPD or randomized prize data stream is an 
aggregate of all of the predetermined outcomes, 5:1-12; the outcome transfer message 
OTM, or the predetermined game outcome, is generated and sent to the player after the 
player has purchased one or more wager-based games or "m" tickets, 5:13-35, the 
OTM is specific to the m tickets and as such is a predetermined outcome for the specific 
number of wager-based games). '640 does not disclose generating the outcomes in the 
random number generator sense, intended by the applicants. '398, however, teaches 
randomly generating outcomes on the fly as purchase requests are made (9:35-10:4, 
esp. 9:48-9:55; 10:23-32). "Turning now to the outcomes/game authorizations that are 
actually communicated to the HTV 20, they are predetermined in the sense that the 
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CMC 12 knows exactly what has been transferred to a given HTV 20 in connection with 
any purchase. In order to facilitate outcome generation, the CMC 12 may include a 
program 42 for generating a random prize data stream ("RPD") 44; a pool containing a 
finite series of win/lose outcomes/game authorizations O.sub.1 . . . O.sub.n (e.g., . . . 
win $2, win $2, lose, lose, win $10, lose, lose . . . etc). In the case of lotteries, the 
aggregate of all winning outcomes/game authorizations in any RPD 44 is a 
predetermined percentage payout of the total revenues to be generated by the sale of 
all "tickets" represented by the outcomes/game authorizations in the RPD 44. However, 
the outcomes may be generated "on the Wa (i.e., contemporaneous with or 
simultaneous to a purchase request). In the illustrative situation where the RPD is 
determined in advance, when a purchase request is received, the CMC 12 utilizes a 
"ticket" (outcome) purchase routine 48 that randomly selects the next m 
outcomes/game authorizations from the RPD 44 (and possibly "standby 
outcomes/game authorizations"-^ to allow for reinvestment of winnings, this will be 
described below) to be assigned to a particular HTV 20. The outcome purchase routine 
48 then directs the CMC 12 to generate an authenticatable game authorization 
message AGAM which is subsequently communicated to and read by the HTV 20 
following one of the protocols described below. For auditing purposes, the outcome 
purchase routine 48 may also direct the CMC 12 to store transactional data in a record 
40, including the outcomes/game authorizations m assigned in field 52, and the standby 
outcomes/game authorizations x assigned in field 54, and optionally, even the AGAM 
itself. Accompanying this data may be the price point for a given "ticket" (outcome) such 
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as $0.25, $1 , $2, etc., in field 56, the net payoff in field 58, and the time/date in field 60. 
Thus, a record is generated in the CMC 12 for each transaction with a given HTV 20." 
"If Another way in which the CMC 12 can assign outcomes/game authorizations is 
through the use of a one-way function which utilizes a seed value to generate a 
sequence of outcomes/game authorizations that are selected from the RPD 44. The 
HTV memory area 36 in the CMC memory 32 includes such a one-way function in field 
62. An identical one-way function is stored in the HTV 20 as described below. The seed 
value for this one-way function becomes part of an authenticatable game authorization 
message AGAM." Tanskanen discussed below (U.S. pre-grant application 
2001/0039204 A1) also suggests such a modification: '204 discloses randomly 
generating outcomes only after being purchased. Para. 8: "...there is no a priori 
knowledge of the value of any ticket in the game." See also Fig. 1 ('204), Para. 21 & 22. 
Para. 16: "Once a selection is made, the betting service randomly selects game tickets 
and transmits them to the user (Step 108). Typically, a debit for each ticket selected will 
be taken from the betting service account of the user. Each game ticket has a lottery ID 
number associated with it that identifies it to the betting service. The lottery ID number 
is transmitted to the user along with the parameters of the game. The parameters can 
include, for example, the button array, game rules, ticket layout, etc. Once received by 
the user, the game ticket can be played on a wireless station." Para. 24: "In an 
alternative embodiment, each game ticket downloaded to a wireless station, or other 
terminal, for playing includes the win/loss information. That is, in addition to the lottery 
ID number and game parameters, information regarding the value behind the button or 
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buttons selected, is known or derived at the wireless station. In this alternative 
embodiment, the betting service provider 210 no longer generates a random value after 
a button is selected. Rather, the betting service provider 210 generates random values 
prior to transmitting the ticket and transmits them with the other gaming parameters." It 
would have been obvious to one of ordinary skill in the art to apply the ad hoc random 
ticket generation of '398 rather than the virtual stack of virtual tickets taught by '640. 
This would obviate the randomized prize datastream of '640 (5:3:12) which is used to 
meet the minimum payout standards. It would reduce the storage required as the 
randomized prize datastream would not have to be stored and also increase security by 
eliminating the stored randomized data stream which could be susceptible to intrusion 
and alteration. Generating the random outcomes on the fly would have a security 
advantage in that stored outcomes would not be able to be altered since no outcomes 
are stored to begin with. This would prevent tampering of outcomes stored on the 
central server. '398 is analogous art to '640 in that both are solving the same problem. 
'398 is an off-line remote lottery system which enables players to purchase instant-type 
lottery game outcomes from a randomized prize data stream in a central computer, and 
view the outcomes on remotely disposed gaming computers which do not require an on- 
line connection during play (Abst. of '398; Abst. of '640). The two references are nearly 
identical in disclosure and are most likely embodiments of the same actual application. 
Additionally, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to have modified '640 such that the physical game server and the 
physical financial server are two separate physical servers. Such a limitation is 
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suggested by Davis, et al. (U.S. patent 6,105,008 A), Fig. 4, which depicts separate 
merchant (analogous to game since virtual tickets are what is being bought in Walker 
'640) and payment (financial) servers. According to '008, this modification has the 
effect and advantage of using existing "back end" servers for processing financial 
transactions. This would relieve the gaming developer from having to develop a 
merchant website and financial software from scratch, as financial transactions are not 
the game developer's core competency. 

1 . As to Claim 17: '640 has a hand-held personal gaming device including a display 
adapted to display gaming related information, a processor configured to execute 
gaming related code, and a memory adapted to store code to be executed by the 
processor (Figs. 4 and 5). The personal gaming device of '640 is adapted to 
communicate with the LCC (Col. 8, Lines 54 to 59), which is a game server and a 
financial server. 

2. As to Claim 18: The storage device is a memory on the HTV of '640 (Figs. 4 and 
5). 

3. As to Claim 19: The storage device is a memory of a personal gaming device 
(Figs. 4 and 5 of '640, ROM and RAM). 

4. As to Claim 20: In '640, the specific number of wager-based games to be played 
comprises a block of games to be paid for in advance before the data regarding the 
predetermined game outcome for each of the specific number of games is transmitted 
to the personal gaming device (player purchases a block of plays, which is then 
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generated and transmitted to the personal playing device (Col. 15, Lines 13 to 27, 40 to 
54; Col. 15, Line 64 to Col. 16, Line 8). 

5. As to Claim 21 : In '640, the game server transmits the data regarding the 
predetermined game outcome for each of the specific number of games to the personal 
gaming device via a wireless link (Col. 5, Lines 49 to 52). 

6. As to Claim 22: In '640, the financial server accepts information from the gaming 
server regarding the predetermined game outcome for each of the specific number of 
games, and reconciles the accepted information with actual results from future game 
play on the gaming device (module 62 of Fig. 4 acts as game server, generating game 
outcomes, module 79 acts as a financial server comparing the purchased games to the 
actual game results to calculate the payout; Col. 1 1 , Lines 3 to 15). 

7. As to Claim 30: In '640, the game server includes a random number generator 
that generates predetermined game outcome for each of the specific number of wager- 
based games to be played on the personal gaming device (outcome generation 62, 
RPD generation 42, Fig. 3; one-way function 62 that seeds random generator 42, Fig. 3; 
Col. 9, Lines 36 to 38; Col. 12, Lines 10 to 18). 

8. As to Claim 34: '640 provides a system having a server (LCC, Fig. 3) adapted to 
generate wager-based game outcomes (Col. 5, Lines 3 to 12), transmit gaming related 
information to one or more personal gaming devices (Col. 8, Lines 53 to 59), and track 
financial data related to the generated game outcomes (52, 56, 58, 48, 79, 72, and 78, 
Fig. 3). '640 accepts input from a user regarding a number of wager-based games to 
be played on a hand-held personal gaming device (Col. 3, Lines 27 to 36; Col. 7, Lines 
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15 to 20), the personal gaming device including a display adapted to display gaming 
related information, a processor configured to execute gaming-related code, and 
memory adapted to store code to be executed by the processor (Figs. 4 and 5). '640 
generates at the system having one server a predetermined game outcome for each of 
the number of wager-based games to be played on the personal gaming device (Col. 5, 
Lines 3 to 12). '640 transmits the predetermined game outcome (Col. 5, Lines 49 to 52) 
for each of the number of games to a storage device (HTV memory, 1 00, Fig. 5) for use 
by the personal gaming device. '640 stores the predetermined game outcome for each 
on the number of games at the personal gaming device for later use (Col. 6, Lines 1 to 
6; Lines 44 to 62). '640 executes code at the personal gaming device using at least one 
stored predetermined game outcome to present a game and at least one stored 
predetermined game outcome at the display (games executed, Col. 8, Lines 42 to 46; 
display and controller, Fig. 4). '640 teaches the game server being configured to 
generate the predetermined game outcome for one or more of the specific number of 
wager-based games only after a user has purchased one or more of the wager-based 
games, in other words, after receiving payment for a wager to play at least one of the 
number of wager-based games (Col. 5, Lines 1 to 35 generally; RPD or randomized 
prize data stream is an aggregate of all of the predetermined outcomes, 5:1-12; the 
outcome transfer message OTM, or the predetermined game outcome, is generated 
and sent to the player only after the player has purchased one or more wager-based 
games or "m" tickets, 5:13-35, the OTM is specific to the m tickets and as such is a 
predetermined outcome for the specific number of wager-based games). Additionally, it 
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would have been obvious to one of ordinary skill in the art at the time the invention was 
made to have modified '640 such that the physical game server and the physical 
financial server are two separate physical servers. The applicants have not stated that 
having separate servers solves any stated problem or is for any particular purpose. 
Moreover, it appears that '640, or the applicants' invention would have performed just 
as well modified such that the game server and the financial server are separate 
physical servers. Accordingly, it would have prima facie obvious to one of ordinary skill 
in the art at the time the invention was made to have modified '640 such that the game 
and financial servers are separate physical servers because such a modification would 
have been considered a mere design choice which fails to patentably distinguish above 
'640. 

9. As to Claim 36: The storage device of '640 is a memory of a personal gaming 
device (memory 100, Fig. 5). 

10. As to Claim 37: '640 stores data regarding predetermined game outcomes for 
each of the number of games at the LCC (Col. 6, Lines 1 to 8). '640 reconciles the 
stored data with actual results from executed game play on the personal gaming device 
(Col. 6, Lines 44 to 62). 

11. As to Claim 38: '640 authenticates the user of the personal gaming device (Col. 

12. Lines 59 to 64). 

12. As to Claim 39: The authentication of '640 is done by a password (Col. 1 2, Lines 
59 to 64). 
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13. Claims 23 and 24 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over '640 and '398 in view of Tanskanen (U.S. pre-grant publication 2001/0039204 A1). 

14. As to Claim 23: The combination of '640 and '398 discloses all of the elements of 
Claim 23, but lacks specificity as to the player authentication server being separate from 
the gaming device. '640 has a player authentication server that processes an 
authentication of a user of the personal gaming device (encryption, Col. 6, Lines 1 7 to 
23; password, Col. 12, Lines 54 to 56). '204, however, teaches a player authentication 
server being separate from the gaming device (user logs in to system and is 
authenticated or declined, Fig. 1 , user authentication done at betting service instead of 
player device, Para. 16). It would have been obvious to one of ordinary skill in the art at 
the time the invention was made to apply the remote authentication of '204 to the 
gaming system of '640 and '398. '640 has two situations in which it would be useful to 
verify the player's identity remotely, rather than locally at the gaming device. The first 
situation is when the buyer purchases tickets (Col. 15, Lines 4 to 42). The second 
situation is when the player is redeeming his or her winnings (Col. 18, Line 54 to Col. 

1 9, Line 25). '640 only verifies the identity of the HTV (portable gaming device) at 
redemption (Col. 6, Lines 44 to 62). It is possible for one of the HTVs in '640 to have 
multiple players (Col. 9, Lines 8 to 12); the HTV has a unique identifier (Col. 9, Lines 13 
to 36). The advantage of this combination would be to enhance the security of the 
gaming system by providing a way to verify the identities of the players when buying 
tickets or cashing out winnings, in addition to verifying the identity of the gaming unit 
itself. 
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15. As to Claim 24: The verification of '640 can be done using a password (Col. 12, 
Lines 54 to 56). 

16. Claim 40 is rejected under 35 U.S.C. 103(a) as being unpatentable over '640 and 
'398 in view of McEntee, et al. (U.S. pre-grant publication 2002/01 1 1213 A1, application 
09/782,497). 

1 7. As to Claim 40: The combination of '640 and '398 discloses all of the elements of 
Claim 25, but lacks specificity as to the verification including a fingerprint of the user of 
the personal gaming device. McEntee, however, in '213 teaches the use of a fingerprint 
to authenticate the user of a personal gaming device in a casino environment (Para. 9, 
40). It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to apply the fingerprint verification of '213 to the combination of 
'640 and '398. '213 uses handheld wireless devices to transmit wagering information in 
a casino network (Abst.), like ('640). '213 uses authentication to verify a player's 
identity and GPS to verify that the player is in a location where wagering is authorized 
(Para. 9 and 1 0), like '640 (Col. 1 1 , Line 66 to Col. 1 2, Line 5; Col. 1 2, Lines 59 to 64). 
The advantage of this combination would be to enhance the security of the gaming 
system by providing fingerprint authentication, which is more secure than a password 
system. 
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18. Claims 25 and 26 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over '640, '398, and '204 in view of McEntee, et al. (U.S. pre-grant publication 
2002/01 1 1 21 3 A1 , application 09/782,497). 

1 9. As to Claim 25: The combination of '640, '398, and '204 discloses all of the 
elements of Claim 25, but lacks specificity as to the verification including a fingerprint of 
the user of the personal gaming device. McEntee, however, in '213 teaches the use of 
a fingerprint to authenticate the user of a personal gaming device in a casino 
environment (Para. 9, 40). It would have been obvious to one of ordinary skill in the art 
at the time the invention was made to apply the fingerprint verification of '213 to the 
combination of '640, '398, and '204. '213 uses handheld wireless devices to transmit 
wagering information in a casino network (Abst), like ('640). '213 uses authentication to 
verify a player's identity and GPS to verify that the player is in a location where 
wagering is authorized (Para. 9 and 10), like '640 (Col. 11, Line 66 to Col. 12, Line 5; 
Col. 12, Lines 59 to 64). The advantage of this combination would be to enhance the 
security of the gaming system by providing fingerprint authentication, which is more 
secure than a password system. 

20. As to Claim 26: '640 authenticates that the player is located in a location where 
gaming is allowed by using GPS (Col. 11, Line 66 to Col. 12, Line 5). 

21 . Claims 27 to 29, 41 , and 44 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Walker ('640) and Schneier ('398) in view of Lemke (U.S. pre-grant 
publication 2002/0066041 A1, application 09/727,984). 
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22. As to Claim 27: The combination of Walker ('640) and Schneier ('398) discloses 
all of the elements of Claim 27, but lacks specificity as to a docking station by which 
gaming data can be transmitted to the personal gaming device. Lemke in '041 , 
however, teaches has a docking station, by which data regarding the predetermined 
game outcome for each of the specific number of games is transmitted to the personal 
gaming device (Fig. 1 A, PDA communicating by RF, Fig. 1 B, PDA communication by 
wire while plugged into cradle, Para. 25). It would have been obvious to one of ordinary 
skill in the art at the time the invention was made to apply the docking station of '041 to 
the combination of '640 and '398. '041 is a wireless PDA application that uses biometric 
information such as fingerprints to grant the user access to the network (Abst., Para. 
36). In one embodiment of '041 , a speech pattern reader is used to verify the identity of 
the user attempting to log on to the wireless network (Para. 44). This could be used in 
conjunction with the voice-activated circuit 1 10 of '640, which enables commands to be 
communicated to the CPU (Col. 1 1 , Lines 56 to 60). In one embodiment of '640, the 
server communicates with the HTVs (personal gaming devices) by landline rather than 
by a wireless connection (Fig. 12). The advantage of this combination would be to allow 
the server to continue communicating with the personal gaming device by wire while the 
personal gaming device is being charged up in the docking station in the event that it 
has run low on power and can no longer transmit. 

23. As to Claim 28: '640 has a hand-held personal gaming device including a display 
adapted to display gaming related information, a processor configured to execute 
gaming related code, and a memory adapted to store code to be executed by the 
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processor (Figs. 4 and 5). The personal gaming device of '640 is adapted to 
communicate with the LCC (Col. 8, Lines 54 to 59), which is a game server and a 
financial server. It is inherent that the combination of '640, '398, and '041 would be able 
to allow the personal gaming device to communicate with the game server, the financial 
server, or both while it is plugged into the docking station (Fig. 1A, PDA communicating 
by RF, Fig. 1B, PDA communication by wire while plugged into cradle, Para. 25). 

24. As to Claim 29: The PDA of '041 is adapted to reside at a docking station (Fig. 4) 
and can be checked out to a user from the docking station by use of biometric 
identification (Para. 36 and 37). '640 teaches a wireless personal gaming device that 
can be checked out to one of any number of users, each user having his or her own 
password (Col. 12, Lines 59 to 64). 

25. As to Claim 41 : Lemke in '041 teaches has a docking station, by which data 
regarding the predetermined game outcome for each of the specific number of games is 
transmitted to the personal gaming device (Fig. 1A, PDA communicating by RF, Fig. 1B, 
PDA communication by wire while plugged into cradle (docking station), Para. 25). 

26. As to Claim 44: '640 teaches a station (15, 600, Fig. 13) configured for use on a 
gaming system to facilitate the play of wager-based games on a personal gaming 
device (Abst., Col. 3, Lines 26 to 36). The station has a link to a game server of the 
gaming system (LCC 12, Fig. 13). The game server is configured to accept input 
regarding a specific number of games to be played on an associated hand-held 
personal gaming device (Col. 5, Lines 13 to 32). The game server generates a 
predetermined game outcome for each of the specific number of wager-based games to 
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be played on the personal gaming device (Col. 5, Lines 3 to 12), and transmits data 
regarding the predetermined game outcome for each of the specific number of games to 
be played on the persona gaming device (Col. 8, Lines 53 to 59). Lemke in '041 
teaches has a docking station, by which data regarding the predetermined game 
outcome for each of the specific number of games is transmitted to the personal gaming 
device (Fig. 1 A, PDA communicating by RF, Fig. 1 B, PDA communication by wire while 
plugged into cradle (docking station), Para. 25). The combination of '640, '398, and 
'041 would provide a docking station for use the personal gaming device, and transmit 
the data regarding the predetermined game outcome for the specific number of games 
to the personal gaming device via the docking station. '640 teaches the game server 
being configured to generate the predetermined game outcome for one or more of the 
specific number of wager-based games only after a user has purchased one or more of 
the wager-based games, in other words, after receiving payment for a wager to play at 
least one of the number of wager-based games (Col. 5, Lines 1 to 35 generally; RPD or 
randomized prize data stream is an aggregate of all of the predetermined outcomes, 
5:1-12; the outcome transfer message OTM, or the predetermined game outcome, is 
generated and sent to the player only after the player has purchased one or more 
wager-based games or "m" tickets, 5:13-35, the OTM is specific to the m tickets and as 
such is a predetermined outcome for the specific number of wager-based games). 
Additionally, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to have modified '640 such that the physical game server and the 
physical financial server are two separate physical servers. The applicants have not 



Application/Control Number: 10/672,307 Page 17 

Art Unit: 3714 

stated that having separate servers solves any stated problem or is for any particular 
purpose. Moreover, it appears that '640, or the applicants' invention would have 
performed just as well modified such that the game server and the financial server are 
separate physical servers. Accordingly, it would have prima facie obvious to one of 
ordinary skill in the art at the time the invention was made to have modified '640 such 
that the game and financial servers are separate physical servers because such a 
modification would have been considered a mere design choice which fails to 
patentably distinguish above '640. 

27. Claims 31 to 33, 42, and 43 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Walker ('640) and Schneier ('398) in view of Jaynes, et al. (U.S. pre- 
grant publication 2002/0085515 A1, application 09/752,214). 

28. As to Claim 31 : The combination of Walker ('640) and Schneier ('398) discloses 
all of the elements of Claim 31 , but lacks specificity as to transmitting activation 
information to a personal gaming device. Jaynes, however, in '515 teaches an infrared 
beacon transmitting an activation signal to a wireless PDA device, allowing the PDA to 
obtain information by transmitting the beacon's identification over the wireless network 
to establish communication with an Internet site (Para. 10). It would have been obvious 
to one of ordinary skill in the art at the time the invention was made to apply the beacon 
activation signal of '515 to the combination of '640 and '398. '515 is a wireless PDA 
system, analogous to the wireless gaming devices of '640 (Fig. 13). '640 uses GPS to 
restrict gaming access to areas where gaming is allowed (Col. 1 1 , Line 66 to Col. 12, 
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Line 5). This combination would have a beacon transmit identification information to the 
wireless PDA (personal gaming device) and only allow the PDA to play the game if it 
transmitted to the game server the correct beacon identification information, which could 
only happen of the PDA were in range of the beacon, in an area of the casino where 
gaming is allowed. The advantage of this combination is that it would use IR beacons 
to restrict gaming access to rooms in the casino or hotel where it is allowed, as GPS 
signals may not always be receivable in indoor environments. 

29. As to Claim 32: In '515, the PDA device is not granted access to the website 
unless it has the correct beacon identification information (Para. 10, 31, 48 to 51). The 
combination of '640, '398, and '515 would not allow the player to place a wager unless it 
received the activation information from the beacon. 

30. As to Claim 33: In '515, the non-reception of activation information is inherently 
due to the device not being within range of the beacon (Para. 10). The device would 
only work when it is in RF or IR range of the beacon. 

31 . As to Claim 42: Jaynes in '515 teaches an infrared beacon transmitting an 
activation signal to a wireless PDA device, allowing the PDA to obtain information by 
transmitting the beacon's identification over the wireless network to establish 
communication with an Internet site (Para. 10). 

32. As to Claim 43: In '515, the PDA device is not granted access to the website 
unless it has the correct beacon identification information (Para. 10, 31, 48 to 51). The 
combination of '640, '398, and '515 would not allow the player to play the wager-based 
games unless the PDA received the activation information from the beacon. 



Application/Control Number: 10/672,307 
Art Unit: 3714 



Page 19 



Response to Arguments 

33. Applicant's arguments with respect to claims 16-34 and 36-44 have been 
considered but are moot in view of the new ground(s) of rejection. 

Conclusion 

34. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Matthew D. Hoel whose telephone number is (571)272- 
5961 . The examiner can normally be reached on Mon. to FrL, 8:00 A.M. to 4:30 P.M. 

35. If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Robert E. Pezzuto can be reached on (571) 272-6996. The fax phone 
number for the organization where this application or proceeding is assigned is 571- 
273-8300. 
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36. Information regarding the status of an application may be obtained from the 

Patent Application Information Retrieval (PAIR) system. Status information for 

published applications may be obtained from either Private PAIR or Public PAIR. 

Status information for unpublished applications is available through Private PAIR only. 

For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 

you have questions on access to the Private PAIR system, contact the Electronic 

Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 

USPTO Customer Service Representative or access to the automated information 

system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

Matthew D. Hoe I /Robert E. Pezzuto/ 

Patent Examiner Supervisory Patent Examiner 

AU3714 Art Unit 3714 

/M. D. H./ 

Examiner, Art Unit 3714 



